package BehavioralPattern.Command;

public interface Readme {

	/**
	 * 一、不用命令模式的不足
	 * (1)我们须要Client和Receiver同时开发,而且在开发过程中分别须要不停重购，改名
     * (2)如果我们要求Redo ,Undo等功能
     * (3)我们须要命令不按照调用执行，而是按照执行时的情况排序，执行
     * (4)开发后期,我们发现必须要log哪些方法执行了,如何在尽量少更改代码的情况下实现.并且渐少重复代码
     * (5)在上边的情况下，我们的接受者有很多，不止一个
     * 
     * 解决办法：
     * 情况一，我们可以定义一个接口，让Receiver实现这个接口,Client按照接口调用。
     * 情况二，我们可以让Receiver记住一些状态，例如执行前的自己的状态，用来undo，但自己记录自己的状态实现起来比较混乱，一般都是一个累记录另一个类的状态
     * 情况三，很难实现
     * 情况四，我们须要在每个Action，前后加上log
     * 情况五，相对好实现，但是再加上这个，是否感觉最终的实现很混乱呢
	 */
	
	/**
	 * 二、命令模式的使用场合
	 * 1,须要callback的时候，例如java awt/swing/swt中的Listening的消息方式
     * 2,须要对请求排队执行，命令的发送者和接受者有不同对的生命周期，就是命令执行的时候，可能发出命令的Client已经不存在了
     * 3,须要Redo Undo等函数
     * 4,须要log每条命令
     * 5,须要支持transaction,封装一组数据命令的时候
	 */
	
	/**
	 * 三、命令模式的优点和缺点
	 * 优点：
     * 降低Client和命令接受者的耦合，是命令请求和命令执行的对象分割
     * 便于修改和扩张
     * 便于聚合多个命令
     * 缺点：
     * 造成出现过多的具体命令类，太多文件。
	 */
	
	/**
	 * 四、命令模式实例
	 * Client  ：看电视的人
     * Invoker ：遥控器
     * Command ：电信号
     * 具体命令 ：遥控器上的按键对应的不同的电信号
     * Receiver：电视机
	 */
}
